fix(automation): stop mention sweep on already-exceeded rate limits - #1027

Rebased the four-commit mention-sweep rate-limit fail-fast series onto current origin/main c47bee5.

Current HEAD: 97f99fb

Validation on this HEAD:

• pytest -q tests/test_agent_mention_rate_limit.py tests/test_agent_mention_sweep.py: 13 passed
• interrogate: 100%
• compileall and git diff --check passed

@OpenCode review this exact HEAD after the rebase.

Exact-current-head repair loop: rebased onto protected main 2cce96f, preserved fail-closed rate-limit classification and operator next action. Current head 2cd701f. Focused rate-limit tests (5) passed; interrogate, compileall, and diff-check passed. Hosted Checks are regenerating; keep Draft and review this exact head only.

Exact-head audit — WAIT_AND_REMEDIATE

• Exact head: 7b1c5c54e6b3d7e481fcbc9ff05019d161a5b0c8
• Exact base: 6a79f075d62b5f8dcfef6145960f1c42c147f273
• PR remains Draft; no merge or bypass is authorized.
• The current tree includes the rate-limit fail-fast repair and a normal merge of the current protected main.
• Focused regression/contract suite: 141 passed.
• git diff --check: passed.
• Local actionlint 1.7.12 reports concurrency.queue as unexpected, but current GitHub Actions documentation defines queue: max (up to 100 pending runs). The workflow is intentionally retained; this is a local validator-version mismatch, not a source failure: https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency
• Hosted required Checks must complete for this exact head, and an independent substantive approval is still absent.

Decision: WAIT_AND_REMEDIATE. Do not force merge.

Exact-head audit — WAIT_AND_REMEDIATE

• Exact head: eaee0aa80501d797439a8eeb90bf33de0d2c7a70
• Exact base: 6a79f075d62b5f8dcfef6145960f1c42c147f273
• Fixed the observed exact-head-path-policy failure: the rate-limit repair branch's Strix contract assertions now match the live scheduler concurrency expressions.
• Local validation: 141 passed, shell syntax passed, and git diff --check passed.
• The PR remains Draft; hosted required Checks must rerun against this exact head and an independent approval is absent.
• The local queue: max warning remains a validator-version mismatch; it is supported by current GitHub Actions syntax and was not weakened.

Decision: WAIT_AND_REMEDIATE.

Exact-head audit update\n\nObserved hosted pip-audit failure on the prior head: PYSEC-2026-3721 through pip 26.1.2.\nRoot-cause fix: refreshed the hash-locked CI dependency to pip 26.2.1 with both package hashes.\n\nExact head: df86ac4\nExact base: 6a79f07\nLocal verification: pip-audit clean; 22 mention-rate-limit/sweep regression tests passed; diff checks passed.\nGitHub currently reports the branch behind and still draft; required checks and exact-head approval remain pending. Decision remains WAIT_AND_REMEDIATE.

Triage (2026-09-02): base history is orphaned, not a resolvable merge conflict

This PR's base commit 0156282022134484ea9d7541d5ba0730ba14fd96 is not an ancestor of current main:

$ git merge-base --is-ancestor 0156282022134484ea9d7541d5ba0730ba14fd96 origin/main && echo yes || echo no
no
$ git merge origin/main --no-edit
fatal: refusing to merge unrelated histories

origin/main now has multiple historical roots (a restructuring/history-splice happened after this branch was cut from an older main), so there is no common ancestor for an ordinary 3-way merge. Forcing --allow-unrelated-histories would diff every shared file against an empty tree and manufacture spurious conflicts across the whole tree — not a real fix, and not something to push through mechanically.

The mergeable_state: dirty GitHub reports here reflects that structural gap, not a normal content conflict this session's usual merge-main-and-resolve recipe can repair.

Next action (needs a human/design call): either (a) reimplement the intent of this PR as a fresh branch cut from current main — the historical commits can't be replayed as-is — or (b) verify whether the underlying gap (mention-sweep rate-limit classification) is already closed on current main, since predecessor #1012 was itself closed unmerged around the same time this history diverged, and close this as superseded if so. Not closing this myself since I haven't verified a live successor covers it. Leaving open pending that decision.

Generated by Claude Code

Retraction — the "main history splice" diagnosis was wrong.

An earlier comment on this PR claimed main's history was spliced onto new roots around 2026-08-20/21, that this PR's base predates the boundary, and that an ordinary merge would fail with fatal: refusing to merge unrelated histories requiring a from-scratch re-implementation. That diagnosis is incorrect — please disregard it entirely.

Root cause: the analysis was run from a shallow git clone in the analysis sandbox (git rev-parse --is-shallow-repository → true). A shallow clone's truncation boundary commits look exactly like disjoint history roots, and git merge from inside a shallow checkout genuinely does throw fatal: refusing to merge unrelated histories even when the real, full history is perfectly linear and connected. After git fetch --unshallow, origin/main has exactly one root commit, and this PR's base is a completely normal ancestor of current main.

This PR should be triaged the ordinary way: fetch a full (non-shallow) clone, git fetch origin main && git merge origin/main --no-edit, resolve any real content conflicts, run the repo's gates, and push. There is no history-splice blocker and no need to abandon or re-implement this PR's work.

Apologies for the incorrect guidance. See #1722 for the corrected writeup.

Generated by Claude Code